Verified here:
https://github.com/brightsign/meta-browser/actions/runs/17671839632

If I use meta-lts-mixins hash 8ed4bf1919453f20d33c492897f93164dc69f4a8 (rust/cargo 1.88)
I can compile it on my targets i.MX6 based cortexa9t2hf-neon and i.MX8 based cortexa53-crypto

But if I update to latest meta-lts-mixins with rust/cargo 1.89. The following happens

| error: hiding a lifetime that's elided elsewhere is confusing
| --> ../../third_party/rust/chromium_crates_io/vendor/qr_code-v2/src/lib.rs:219:17
| |
| 219 | pub fn iter(&self) -> QrCodeIterator {
| | ^^^^^ -------------- the same lifetime is hidden here
| | |
| | the lifetime is elided here
| |
| = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
| note: the lint level is defined here
| --> ../../third_party/rust/chromium_crates_io/vendor/qr_code-v2/src/lib.rs:8:9
| |
| 8 | #![deny(warnings)]
| | ^^^^^^^^
| = note: #[deny(mismatched_lifetime_syntaxes)] implied by #[deny(warnings)]
| help: use '_ for type paths
| |
| 219 | pub fn iter(&self) -> QrCodeIterator<'> {
| | ++++
|
| error: hiding a lifetime that's elided elsewhere is confusing
| --> ../../third_party/rust/chromium_crates_io/vendor/qr_code-v2/src/optimize.rs:112:22
| |
| 112 | pub fn new(data: &[u8]) -> Parser {
| | ^^^^^ ------ the same lifetime is hidden here
| | |
| | the lifetime is elided here
| |
| = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
| help: use '_ for type paths
| |
| 112 | pub fn new(data: &[u8]) -> Parser<'> {
| | ++++
|
| error: aborting due to 2 previous errors
|
| [1590/14681] arm-pmc-linux-gnueabi-clang++ -

Old code does not compile with new Rust. Changes are tested with
meta-lts-mixins: "96deb45139df027473faf0938fe006d33c45c375"

Chromium uses always uses latest compilers, the issue is probably fixed upstream. The fix needs to be backported if aim is to always stay on tip of the tree of the branches on all required layers. I don't know what is meta-browser's strategy on this.

@kraj @otavio Do you the strategy?
The PR works by creation. Then meta-lts-mixins got updated, which courses it not to work.

I am not talking for meta-chromium folks, nor trying to suggest anything - but maybe this is useful for anyone with anything: for Firefox I include in the readme which Rust version from which repository was used to test compile the browser: https://github.com/OSSystems/meta-browser/tree/master/meta-firefox (scroll to the table in the middle)
Not saying that I wouldn't look into issues reported with other versions, but I intend this as a baseline for the users, what they can expect to work.

@caneraltinbasak pushed fixes on brightsign#16 , please review and merge.

@caneraltinbasak pushed fixes on brightsign#16 , please review and merge.

BTW, tested build using your hashes. In the above mentioned MR, added those hashes dependencies both in the README and commit log message:

Test dependencies:
------------------

* URI: git://git.yoctoproject.org/poky
  - branch: scarthgap
  - revision: ac257900c33754957b2696529682029d997a8f28

* URI: git://git.openembedded.org/meta-openembedded
  - layers: meta-oe
  - branch: scarthgap
  - revision: 491671faee11ea131feab5a3a451d1a01deb2ab1

* URI: git://github.com/kraj/meta-clang
  - branch: scarthgap-clang20
  - revision: 76596813cd0061bd9818a80926e6900af61fcaa0

* URI: git://git.yoctoproject.org/meta-lts-mixins
  - branch: scarthgap/rust
  - revision: 96deb45139df027473faf0938fe006d33c45c375